DeepWiki

04 - Payment-Processing

Relevant source files

This document covers the payment processing system in godeep.wiki, which handles the $10 payment from customers through Stripe integration. The payment system consists of three key components: checkout session creation, webhook event handling, and correlation with GitHub installations. This page provides an overview of the payment architecture and data flow.

For detailed information about specific subsystems, see:

  • Checkout session creation: 4.1
  • Webhook handling: 4.2
  • Payment-to-installation linking: 4.3

For GitHub OAuth flow that follows payment, see 3. For the automation system triggered by payment, see 5.

The payment system uses Stripe Checkout Sessions for payment processing, with webhook-based event handling to track successful payments. The architecture is designed to be stateless, relying on the session_id as the correlation key that links payment to subsequent GitHub repository access.

Sources: app/actions.ts L1-L34

app/api/webhooks/stripe/route.ts L1-L93

CLAUDE.md L33-L50

ComponentFile PathPurpose
Checkout Session Creatorapp/actions.tsServer action that initializes Stripe checkout with $10 product
Webhook Handlerapp/api/webhooks/stripe/route.tsReceives and processes Stripe webhook events
Stripe Clientlib/stripe.tsInitialized Stripe SDK instance
Success Pageapp/success/page.tsxReceives session_id from redirect

Sources: app/actions.ts L1-L34

app/api/webhooks/stripe/route.ts L1-L93

The system sells a single fixed-price product with the following specifications:

PropertyValueLocation
Product Name"DeepWiki Analysis"app/actions.ts L17
Description"Full architectural documentation for your GitHub repository."app/actions.ts L18
Price$10.00 USDapp/actions.ts L20
CurrencyUSDapp/actions.ts L15
Payment ModeOne-time paymentapp/actions.ts L25

The price is hardcoded as unit_amount: 1000 (1000 cents = $10.00) in the checkout session creation.

Sources: app/actions.ts L11-L28

The session_id generated by Stripe serves as the primary correlation key throughout the system. This identifier links multiple system events:

The session_id enables manual correlation between:

  1. Payment records in Stripe Dashboard
  2. GitHub installation events in Vercel logs
  3. Webhook notifications in ntfy.sh
  4. OAuth callback logs linking payment to installation_id

Sources: CLAUDE.md L44-L50

app/api/webhooks/stripe/route.ts L54-L68

The webhook handler processes Stripe events asynchronously from the payment flow. This provides reliable notification even if the user closes their browser after payment.

Event TypeActionOutput
checkout.session.completedLog payment details, send ntfy notificationConsole logs + ntfy message

The handler only processes the checkout.session.completed event, which fires when a checkout session successfully completes payment.

Sources: app/api/webhooks/stripe/route.ts L22-L44

When a payment completes, the webhook handler sends a notification to ntfy.sh containing:

FieldExamplePurpose
Amount"$10.00"Payment amount
Customer Email"user@example.com"From session.customer_email or customer_details.email
Match IDLast 12 chars of session_idFor correlation with GitHub installation
TimestampAmerica/New_York timezoneWhen payment received
Message"Waiting for customer to connect GitHub..."Status indicator

The notification is sent to topic NTFY_TOPIC (default: godeep-wiki-payments) with priority "high" and tags "moneybag,tada".

Sources: app/api/webhooks/stripe/route.ts L61-L79

New GoDeep.wiki Sale!

šŸ’° Amount: $10.00
šŸ“§ Customer: user@example.com
šŸ”‘ Match ID: abc123def456
ā° Time: 12/25/2024, 3:45:00 PM

āš ļø Waiting for customer to connect GitHub...
Match this ID with Step 2 notification.

The "Match ID" is the last 12 characters of the session_id, extracted using session.id.slice(-12). This shortened identifier helps the owner manually correlate payment with GitHub installation when checking logs.

Sources: app/api/webhooks/stripe/route.ts L66-L68

The checkout session configures two redirect URLs:

The success_url includes a placeholder {CHECKOUT_SESSION_ID} which Stripe automatically replaces with the actual session ID before redirecting. This ensures the success page receives the correlation key.

The cancel_url redirects back to the landing page with a query parameter indicating cancellation, allowing the UI to display appropriate messaging.

Sources: app/actions.ts L26-L27

VariablePurposeUsed By
STRIPE_SECRET_KEYStripe API authenticationapp/actions.ts L4
lib/stripe.ts
STRIPE_PUBLISHABLE_KEYPublic key for Stripe.js (not used in server actions)Client-side only
STRIPE_WEBHOOK_SECRETWebhook signature verificationapp/api/webhooks/stripe/route.ts L30
NTFY_TOPICntfy.sh topic for notificationsapp/api/webhooks/stripe/route.ts L62

The STRIPE_WEBHOOK_SECRET must match the webhook secret configured in the Stripe Dashboard for the webhook endpoint URL.

Sources: CLAUDE.md L88-L109

app/api/webhooks/stripe/route.ts L30-L35

The system implements multiple layers of error handling:

Error ConditionHTTP StatusResponse
Missing stripe-signature header400"Missing stripe-signature header"
STRIPE_WEBHOOK_SECRET not configured500"Webhook secret not configured"
Signature verification fails400"Webhook Error: [message]"
Event processing exception500"Error processing webhook"

All errors are logged to console with descriptive messages before returning HTTP error responses.

Sources: app/api/webhooks/stripe/route.ts L26-L44

app/api/webhooks/stripe/route.ts L88-L91

The webhook endpoint supports multiple HTTP methods:

MethodPurposeResponse
POSTProcess webhook eventsJSON { received: true }
GETHealth check / verification"Stripe webhook endpoint is active"
OPTIONSCORS preflight200 with CORS headers

The OPTIONS handler enables CORS preflight requests with the following headers:

  • Access-Control-Allow-Origin: *
  • Access-Control-Allow-Methods: POST, OPTIONS
  • Access-Control-Allow-Headers: Content-Type, stripe-signature

Sources: app/api/webhooks/stripe/route.ts L5-L20

The webhook handler logs comprehensive payment information to Vercel logs (stdout):

================================================================================
šŸ’° NEW PAYMENT RECEIVED
================================================================================
Session ID: cs_test_xxx...
Amount: $10
Customer Email: user@example.com
Payment Status: paid
Timestamp: 2024-12-25T15:45:00.000Z
================================================================================

This logging provides an audit trail for payment tracking and debugging. The session_id logged here can be manually correlated with installation_id logged by the OAuth callback handler (see 3.3).

Sources: app/api/webhooks/stripe/route.ts L51-L59

The payment notification sent to ntfy.sh triggers the automation pipeline (see 5). The automation scripts subscribe to the ntfy topic and receive notifications, but they cannot act until the customer also completes GitHub installation, which generates a second notification containing the installation_id.

The two-step notification system (payment + GitHub connection) ensures the owner has both:

  1. Confirmation of payment (from webhook)
  2. Repository access credentials (from OAuth callback)

Only when both notifications are received and manually correlated can the owner proceed with repository cloning and documentation generation.

Sources: app/api/webhooks/stripe/route.ts L61-L81

CLAUDE.md L33-L50

Refresh this wiki

Last indexed: 23 November 2025 (922b35)

On this page

Ask Devin about godeep.wiki-jb

04 - Payment-Processing | DeepWiki | godeep.wiki